The rollups-espresso-reader does a weird thing: it publishes two endpoints /nonce and /submit on a port configurable with env ESPRESSO_SERVICE_ENDPOINT (default I think is 8080). We'd need to expose these too.

What do you think about this format?

• /espresso/reader/nonce
• /espresso/reader/submit

If the developer interaction if gonna be focused on those endpoints, we could even hide everything from espresso-dev-node and only publish those at /espresso/submit and /espresso/nonce, also.

@miltonjonat I sent a fixup where you can access those endpoints at:

• http://localhost:8080/espresso/reader/nonce
• http://localhost:8080/espresso/reader/submit

Please, let me know if it works!

So, these endpoints are currently conveniences for the Espresso integration, and strictly speaking they could (or should?) be part of another component separate from the reader itself. So, no, I wouldn't use "reader" there.

Frankly, I think it's also quite odd to put it under "espresso" in this context, because that "espresso" there is meant to be the (local) Espresso Network, while these are endpoints on the Node itself.

Tbh, the idea here was also that the Node would provide /nonce and /submit functionalities as something more universal (i.e., to also be used when integrated with Avail, Celestia, etc). And that clients wouldn't even know which alt-DA was being used by the app/node.

TL;DR, I'd use http://localhost:8080/nonce and http://localhost:8080/submit directly; or we could come up with a nice namespace for convenience endpoints of this kind (maybe http://localhost:8080/tx/nonce?)

I understand there is no unified way to send a transaction. anvil expects ethereum transactions as specified by eth_sendTransaction, espresso expects a transaction object, avail has its own spec.

So having a single /nonce and /submit at the root of the service, regardless the configured DA, with various formats will be extremely confusing.

I'm exposing those espresso-dev-node ports to the host to test if thins are working, but they should be removed on the final version of this PR togethers with the /espresso endpoints for the proxy.

About the /nonce and /submit endpoints from the espresso-reader, I need a definition so I can apply in this PR.

I understand there is no unified way to send a transaction. anvil expects ethereum transactions as specified by eth_sendTransaction, espresso expects a transaction object, avail has its own spec.

So having a single /nonce and /submit at the root of the service, regardless the configured DA, with various formats will be extremely confusing.

I see this differently. With Paio, we standardized an EIP-712 structure to be used when submitting tx's. This structure includes the target chainId and app address, nonce, and envisions payment info too. Avail and Celestia integrations would use this via Paio, and we adopted it for the Espresso integration as well (Espresso itself doesn't have any spec on the payload you submit, which doesn't even need to be signed atm). The idea is that you would use /nonce and /submit for all L2 tx submissions (i.e., that use Paio / alt-DA), while of course clients would still send direct L1 Eth tx's via the InputBox for L1->L2 messages.

Now, another interesting discussion would be to provide a standard Eth JSON-RPC API on the Node for these L2 tx's. I'd like that, but I don't know how viable it is. It would be part of that redesign discussion for all this architecture.

So, one path what would be very adherent to the current architecture would be something like L2tx, leading to http://localhost:8080/L2tx/nonce and http://localhost:8080/L2tx/submit (I suggested tx above, but I admit that L2tx would be more precise)

How are you going to use a single format for DAs with different requirements?
I.e. how do you define the namespace in case of Espresso?

In the current design, the client/user does not inform any DA-specific parameters in the payload it submits. Whatever is required to submit to the alt-DA configured for the application should be given by DA-specific parameters defined upon deployment of the app, and stored as on-chain app configuration. The Node will fetch that from the application contract (it's currently defined as an ABI encoded method+parameters), and thus know how to handle tx submission when /submit is called.